1. Technical Field
The present invention relates generally to an improved distributed data processing system and in particular to a method and apparatus for a distributed application comprising objects on clients and servers within the distributed data processing system.
2. Description of Related Art
Software developers face the fundamental problem that writing an enterprise-wide application is difficult, and writing a distributed application is even more difficult. In addition, an enterprise seeks to build an application as fast as possible without being locked into one platform. Ideally, enterprise developers would like to be able to write the application once and run it on all of their platforms. Enterprise JavaBeans.TM. technology seeks to provide this ability.
The Enterprise JavaBeans (EJB) component architecture is designed to enable enterprises to build scalable, secure, multi-platform, business-critical applications as reusable, server-side components. Its purpose is to solve the enterprise problems by allowing the enterprise developer to focus only on writing business logic.
The EJB specification creates an infrastructure that takes care of the system-level programming, such as transactions, security, threading, naming, object-life cycle, resource pooling, remote access, and persistence. It also simplifies access to existing applications, and provides a uniform application development model for tool creation use.
Java provides a mechanism by which a Java client can invoke methods on a Java server that is running in a separate process using a methodology called Remote Method Invocation (RMI) However, if the server is not running in a Java environment, such as a CORBA-compliant (Common Object Request Broker Architecture) server, then the Java client is unable to make any method calls to the method on the CORBA server since Java does not provide an inherent mechanism for communicating with CORBA objects.
Simply stated, CORBA is an Object Request Broker (ORB) that allows applications to communicate with one another no matter where they are located or who has designed them. An ORB is the middleware that establishes the client-server relationships between objects. Enterprises have turned to CORBA as a solution to provide inter-operability between various software applications.
When an application is deployed on a CORBA server, the deployer of such an application decides how to save the application's state information so that the deployer can resurrect the application to its correct state after the application has been passivated. Although the state information can be stored persistently by the application itself, typically the container of the server application manages this state information so that the server application is not concerned with the specifics of the back-end store that persists the state information.
Most back-end data stores allow the persistence of primitive data types. However, if a server application running inside a CORBA server needs to persist references to other servers, there is no direct way of doing so. This is especially true for a CORBA server that executes EJBs.
According to the EJB standard specification, the state information of an EJB can be persisted by serializing the EJBHandle that can be obtained from the EJB. The EJBHandle object is supposed to store within itself all the information necessary to resurrect the EJB. However, the use of EJBHandle poses the following problems.
First, portability is a problem. An EJBHandle is a very Java-specific and EJB-specific way of persisting EJB references. A C++ client or some other type of non-EJB client can not construct a remote object from a serialized EJBHandle.
The second problem is the implementation of EJB Handles. An EJBHandle is a Java interface defined in the EJB standard specification. A serialized EJBHandle object contains references to the Handle implementation class. The EJB server is responsible for defining the implementation for EJBHandle. Different EJB servers can have different EJBHandle implementations. Therefore, it may not be possible for an EJB server to resurrect an EJB from a serialized EJBHandle since it may have a completely different implementation class for that Handle, especially if the EJBHandle was serialized by a different EJB server.
Hence, serializing an EJBHandle is not a foolproof method to persist EJB references in container-managed entity beans. Another method that can uniquely identify an EJB and can be used to persist an EJB is to store the Home Name and Key value of the EJB. This information can be enough to locate the referred EJB. However, this information may not always be available at runtime. For example, according to the EJB standard specification, the Home Name is not available to a bean at runtime. Therefore, one cannot persist EJBs by storing their Home Name and Key value.
Therefore, it would be advantageous to have a method for enabling the transparent persistence of an object reference for a JavaBean as a container-managed field within a CORBA server.